js_parser: keep top-level classes module-scoped when lowering top-level using - #38292

Stacked on #38284 (this PR's base is its branch); see the sequencing bullet under Fix. Only the last commit is this PR.

Problem

• In a module with a top-level using / await using, built for any target that lowers using (browser, node; --target=bun is unaffected), top-level class declarations end up in the wrong scope. Affects bun build, bun build --no-bundle, Bun.Transpiler, the bake client bundle and the REPL. Reproduces on 1.4.0 and main; found by inspection, no user report for this exact shape.
• An exported class is hoisted above the generated try/catch, so it runs before the using values it comes after are initialized: static v = foo.v throws TypeError: Cannot read properties of undefined (reading 'v'), and a field like static v = foo?.v is silently undefined. export class Sub extends Base {} with a non-exported Base throws ReferenceError: Base is not defined, because only Sub is hoisted.
• A non-exported class stays inside the try block as a block-scoped declaration, while function declarations are hoisted out of it, so an exported function that uses the class throws ReferenceError: Bar is not defined when called. Same for the export getters of --format=cjs / iife output.
• Cause: the SClass arm of LowerUsingDeclarationsContext::finalize (src/js_parser/p.rs), added in hoisting of exports when there is top level using #14313 for export and using keywords cannot be used in the same file #13734, moved export class out of the try block because an export is not allowed inside a block, and let the others fall into it unchanged. The comment above will_wrap_module_in_try_catch_for_using in src/js_parser/parse/parse_entry.rs describes the class being turned into a var, but nothing implemented that.

Fix

• s_class (src/js_parser/visit/visit_stmt.rs): when the module is going to be wrapped for using and the class is at module scope, the class statement returned by lower_class is replaced with var Foo = class Foo {}, keeping its export flag (convert_class_stmt_to_var). It then takes the path export const / export let already take in this mode: finalize moves the binding into the export clause it emits after the try/catch, the export scan (which runs after visiting) picks it up from there, and when bundling js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284 relocates the var like every other one in the block.
• The SClass arm in finalize is removed. Module-level classes now arrive there as locals, and a class statement in a nested block is never exported, so the arm had nothing left to do. The export and using keywords cannot be used in the same file #13734 shape it was added for (export class declared before the using that instantiates it) is still covered by the existing edgecase/UsingExportClass, now through the export clause.
• Why this is correct: the var is initialized at the same point in evaluation order as the declaration was; it is module-scoped, so the hoisted function declarations and the importing modules can reach it; and later assignments to the binding (decorator lowering emits Foo = __decorateElement(..., Foo) after the class) still reach the export through the clause. The class expression keeps its name, so .name and references to Foo from inside the class body behave as before. esbuild emits the same thing for this input (var Bar = class {...} and var Baz = class {...} inside the try, export { Baz } after it).
• Decorated classes go through the same replacement: the extra statements lower_class emits around a class (both decorator flavors) refer to the class by symbol, so they keep working against the var. Also checked by hand: TS class/namespace merging, --minify, --format=cjs / iife, and the REPL.
• Sequencing: when bundling, a module that is also reached through import() is evaluated inside an __esm(...) wrapper, and the linker only hoists top-level statements out of it. The vars inside the try block are hoisted by js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284, so this PR is based on it and has to land after it. On main alone, this change would turn an exported class that does not touch the using values in such a module from working (it was hoisted above the try) into a ReferenceError at the export getter, the state export const is in today. edgecase/UsingTopLevelClassDeclarationsInEsmWrapper pins this down: it passes on this stack, fails on js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284's branch without this change (TypeError, class evaluated too early) and fails on main plus this change alone (var Exported left inside the wrapper), so CI enforces the order.
• Tests: test/bundler/bundler_edgecase.test.ts (edgecase/UsingTopLevelClassDeclarations, UsingTopLevelClassDeclarationsInEsmWrapper, AwaitUsingTopLevelClassDeclarations, UsingTopLevelClassStandardDecorators, UsingTopLevelClassExperimentalDecorators, UsingTopLevelClassBakeDev) and test/bundler/transpiler/transpiler.test.js (using top level turns class declarations into vars, a snapshot of the non-bundled Bun.Transpiler output, which js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284 does not affect). All seven fail on the base branch without the src/ change and pass with it. The bundler tests only assert Foo = class for the rewritten classes, since the var is relocated when bundling and the expression's name is not what they are about.
• Also passing on the stack: the rest of bundler_edgecase (including js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284's tests and UsingExportClass), bundler_browser, bundler_minify, esbuild/{lower,ts,default}, transpiler/{transpiler,decorators,es-decorators,es-decorators-esbuild,decorator-metadata}, bundler_decorator_metadata, lower-using-bun-target, explicit-resource-management, bake/dev-and-prod (using runtime import).
• Related PRs: Convert top-level class statements to var declarations when bundling #32655 adds the same class-to-var rewrite to these s_class lines for all bundled output (size motivation; its condition already includes the using mode but it has no using coverage and has been open since June), so the two conflict textually; if it is picked up it can widen the condition here and add its name dropping inside convert_class_stmt_to_var. js_parser: keep export default function/class when lowering top-level using #38287 handles export default function/class in this mode and removes the finalize arm adjacent to the one removed here, so whichever of the two lands second needs a trivial rebase. js_parser: keep destructured exports when lowering top-level using #38279 (destructured exports) touches a different part of the same function.

Background

• Lowering using: for targets without native using, the parser rewrites using x = v into var x = __using(stack, v) and wraps the statements that follow in try { ... } catch { ... } finally { __callDispose(stack, ...) }. At module level the whole module body ends up inside that try block. will_wrap_module_in_try_catch_for_using is set before the visit pass so statements can be adjusted while they are visited; finalize builds the try/catch afterwards.
• Function declarations are kept outside the try block because ESM hoists them: an importer in a cycle may call them before this module's body has run. Anything such a function refers to therefore has to be visible at module scope, which is why this mode already turns top-level let / const into var (select_local_kind); a class declaration is block-scoped like let, so it needs the same treatment.
• export declarations are only valid directly at module level, so an exported binding inside the try block is exported through an export { ... } clause placed after it. Bun's export list (named_exports) is computed from the visited statements, so the clause is what makes the export exist.
• __esm wrapper: when bundling, a module that must be evaluated lazily (for example because it is import()ed) has its body wrapped in a closure, and the linker turns the module's top-level declarations into declarations outside the closure plus assignments inside it, so the export getters can reach them. Declarations nested in the try block are invisible to that pass unless the parser relocates them first, which is what js_parser: hoist the declarations of a lowered top-level using out of the ESM wrapper and the REPL IIFE #38284 adds.
• lower_class returns the class statement plus any statements decorator lowering adds around it; the replacement swaps out the class statement within that list.

// cls.mjs
using foo = { v: 1, [Symbol.dispose]() {} };
class Bar { static v = foo.v; }
export function fn() { return new Bar().constructor.v; }
export class Baz { static v = foo.v; }

// entry.mjs
import { fn, Baz } from "./cls.mjs";
console.log("fn():", fn(), "Baz.v:", Baz.v);

$ node entry.mjs
fn(): 1 Baz.v: 1
$ bun build --target=browser entry.mjs --outfile=out.mjs && node out.mjs   # 1.4.0
TypeError: Cannot read properties of undefined (reading 'v')

function fn() { return new Bar().constructor.v; }
class Baz { static v = foo.v; }          // runs before `foo` is assigned
let __stack = [];
try {
  var foo = __using(__stack, { v: 1, [Symbol.dispose]() {} }, 0);
  class Bar { static v = foo.v; }        // scoped to the try block; fn() cannot see it
} catch (_catch) { var _err = _catch, _hasErr = 1; } finally { __callDispose(__stack, _err, _hasErr); }

function fn() { return new Bar().constructor.v; }
let __stack = [];
try {
  foo = __using(__stack, { v: 1, [Symbol.dispose]() {} }, 0);
  Bar = class Bar { static v = foo.v; };
  Baz = class Baz { static v = foo.v; };
} catch (_catch) { var _err = _catch, _hasErr = 1; } finally { __callDispose(__stack, _err, _hasErr); }
var foo;
var Bar;
var Baz;

export function fn() { return new Bar().constructor.v; }
let __bun_temp_ref_1$ = [];
try {
  var foo = __using(__bun_temp_ref_1$, { v: 1, [Symbol.dispose]() {} }, 0);
  var Bar = class Bar { static v = foo.v; };
  var Baz = class Baz { static v = foo.v; };
} catch (__bun_temp_ref_2$) { ... } finally { ... }
export { Baz };